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360/H30_Coamanicationsi_Stabler^_Krafchin t _Sgag§wick 

During the past contract period we have been engaged in a 
review of various systems (existing and planned) supporting 
communications between a S/360 and a remote 1130 over high speed 
(40,800 baud) BSC line. A proposal for our 1130-360 graphics 
system was presented at a meeting with Messrs. Matsu, Eulla, 
Johnson, and various other IBM personnel in December, 1958. The 
proposal was on the whole accepted, and priorities for the 
completion of its various phases were established. 

Our first objective will be to provide support for existing 
2250 MOD I users. This will require a conversion of MOD I to MOD 
IV graphic orders and communications between the 360 and the 
1130. " The second phase of our system will provide a general 
facility for all graphic applications from the 350. The third 
stage of our research project will integrate this generalized 
graphics capability with a symmetric call proceeding facility 
from either processor. Progress made since the December meeting 
is outlined below. 


360_Communications_Routines 

The 360 side of the 360/1130 interface has been received from 
Cambridge and is in the process of being modified to fit our 
needs. Included in the changes being undertaken are: 

(1) Modification of the message blocking and error handling 
routines. This is made necessary by the lack of intermediate 
transmission block (ITB) characters on the 1130 high speed RP 2 ♦ 

(2) Allowance for multiple tasks in the 360 under either MFT 
or MVT (not presently supported by the Cambridge code). 


(3) Provision for error statistics and a trace table for 
360/1130 I/O. 

Cambridge work is being monitored for changes generated by their 
tests of the system on their low speed line. 


113Q_Cgmmunications R ou tines 

Coding for the 1130 I/O monitor, wait executor, and core 
management package has just recently been completed at Cambridge 
and "will be received during the first weak of February. A 
low-level high-speed communications routine for use by the 1/0 
monitor which will be call — compatible with the 1 ow-speed S*,AT4 is 
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now beinq developed from a high-speed SCAT2 routine that was 
written at Ohio State University. This will provide us with a 
general purpose high-speed communications routine and should 
require little or no change in the coding being received from 
Cambridge. 


Graghic_Support_for_Staqe_1 


The basic conversion of MOD I orders to MOD IV orders has been 
coded and debugged on the 360. The fundamental problem of 
compatibility has been solved, in many instances by software 
support in the 1130. Before an extensive amount of time was 
invested in coding and debugging the 1130 side of graphics 


support, advantage was taken of the 
Plains. This debugging session proved 
solving certain difficult areas (e.g. 
cursor manipulation). 


MOD IV facilities in White 
to be an invaluable aid in 
attention handling and 


Sketchpad^_Dan_Bergeron 

From October to December, 1968, the primary addition to the 
Virtual Sketchpad System was the on-line ability to specify (or 
change) which data sets should be retrieved. 

Considerable effort has also been aimed at reducing the size 
of the system. Currently, program requirements have been reduced 
to 45K bytes, but access methods and data areas require another 
45-55K bytes. With some limitations the system can now be run in 
a 98K partition. These limitations should soon be removed. 

The Information Retrieval System is still being tested and 
further improved. The circle drawing routines have been rewrit¬ 
ten to create eguilength arcs and to allow erasure while 
retracing the circle. A link to a CALCOHP plotting routine has 
been added allowing hard copy output of the scope display. 

A user’s manual has been produced and will accompany distribu¬ 
tion of the system. 


3DPDP: Charles_Strauss 


During the past contract 
cleaning up 3DPDP, documenting 


period I have 
3DPDP both for my 


been engaged in 
dissertation and 
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Hypert ex t Editing Sy stem:_A^_yai^Darn^S._Carmoi 


The Hypertext Editing System has been continuously evolving 
since June. In the package currently being made available (and 
in use at the New York Scientific Center) there exist a number of 
new editing and formatting options. These changes and additions 
are described in two detailed reference manuals (Edit Phase and 
Format Phase), and the system as a whole is described in a paper 
to be presented at the second annual Computer Graphics Conference 
at the University of Illinois in March, 1969 . A card input 
program provides an inexpensive means for inputting rough draft 
texts, and text from different data sets may also be combined and 
merged. 

The current system is in use minimally 8 hours per day, and 
all our systems documentation, including the 135 page SOS manual, 
are being (or have been) produced with it. 


T§blet-driven_Editing_SY§tem:_Nark_Pozef sky 


This editing system is designed to accept character strings 
from a pattern recognition system (which is to be provided by the 
NYC Scientific Center) and incorporate these strings into the 
data structure for a given text. The editing system then 
displays the change in the manuscript that was just called for, 
allowing the user to accept or reject his proposed changes (a la 
Hypertext Editing System). 


£l 2 D._Data_Structuregx_Alan Blitzblau 


In the past four months, I have been actively completing and 
debugging the Dynamic Storage Allocation (DSA) and Data Structure 
(DS) routines for PLAN. A preliminary version of DSA (maximum of 
32K pages, and some undebugged features) was sent to White Plains 
for testing near the end of November. Since then I have 
completed the major debugging of the Data Structure subroutines, 
and they were sent to White Plains in December for tasting along 
with DSA. I have added the coda for 128K pages and an EDV trap 
to DSA, which are in the final stages of debugging. In addition, 
a bug in DSA (in one of the paging routines) which previously 
would not allow us to save DSA data sets has been fixed, and the 
updated routines were subsequently sent to White Plains. Until 
DSA is completed, however. White Plains can run realistic tests 
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of DS 
have. 


and 


using the version of the system they currently 


Fl ow chart _Pro 2 raffl min g_S]£steni^ I§;S§§_Michener 


During the past months the Flowchart Programming 
been switched over from using an incore workarea 
flowchart to a multi-flowchart paged system, using 
under HPT (developed for DSPS). The 
desirable additions to make full use of a p 
been added. 


For instance, the system uses an "act 
track of the flowcharts (and pages of text, s 
is currently interested in. Each entry in 
the flowchart, the viewpoint for displaying 
the scaling of the view. The latter is also 
scales are available (1, 1/2, 1/4, 1/8). 

normal case, and is the only scale for 
flowchart symbols is displayed. The other 
see more of his flowchart at once. 


System has 
for a single 
BEAM paging 
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Another CALCOHP facility which simply translates 
grams has been released to 3DPDP, to SKETCHPAD 
George Stabler's FORTRAN Graphics Package. 


buffer pro- 
■I. R. , and to 


Facilities for text editing will be added soon; these will 
enable the user to create pages of text without flowcharting. A 
user might want to do this for long sections of comments or for 
long computational formulae. 


A data set back-up 
Hypertext Editing System, 
DSPS type paged data set. 


facility, patterned after that of the 
will be debugged soon for use with any 
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A users manual for the Flowchart Editor has been 
under HYPERTEXT and is available. 


prepared 
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INTRODUCTION 


The follov?ing pages describe 
subroutines whose purpose is to provide simple, high 
to the facilities offered by the IBM 2250-HOD 1 
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GENERAL DESCRIPTION 


The following paragraphs describe some of the main concepts 
used in the system, particularly those involved in the interface 
between the user’s program and the graphics subroutines. Hhat is 
left unsaid will be clarified in the descriptions of the 
individual subroutines. 
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Graphic data, whether generated by the user or the system on 
request from the user, is stored in one of several user defined 
arrays which are dimensioned 4xN, N being chosen by the user. To 
set up a standard example, the statement 'DIMENSION A (4,100)* 
would reserve space for 100 data items, the Ith item occupying 
A (1,1) through A (4,1). The first three of these locations, 
A(1,1)-A(3,1) , are, with certain restrictions noted below, avail¬ 
able to both the user and the graphics subroutines. The fourth, 
A(4,I), is reserved for system use and should never be refered to 
by the user (with the possible exception of copying one array 
into another). 

The contents of the first three words of an item are a 
function of the type of item, which can be point, line, text, or 
plot. These will be described in turn and are shown graphically 
in figure 1. 


The Point Item 


A{1,I) - The X coordinate, in user's units of the point. It 
should be noted that hare and in all that follows, that all 
coordinate values are kept in single precision floating point 
(REAL* 4) form. 


A(2,1) - The Y coordinate of the point. 


A(3,1) - A coda representing the type of item contained in 
this 'column* of the array. For a point, this code is 1.0. The 
function of this code is explained in the section on adding and 
deleting data items. 


The Line Item 


A line 
of which 

2 . 0 . 


is specified 
are given as 


by two consecutive points, the 
above. The type code for each 


cooriina tes 
endpoint is 
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§L J BROUTIN|_DESCRIPTigNS 
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Name of 

Subroutine: GOPEN 

Purpose: 

: To initialize graphics system. 

Calling 

Sequence: CALL GOPEN 

Notes: 

GOPEN must be called before reference to any 
of the other graphics subroutines is made. 
Thereafter it should not be called again 
without an intervening call to GCLOSE (see 
description of GCLOSE) . 


PROJECT GRAPHICS 14 



9TH CONTRACT PERIOD 


FORTRAN GRAPHICS SUBROUTINES 31 JANUARY', 1969 


Name of Subroutine: DEFINE 


Purpose: To inform the graphics system of an array 

which is to be used for storing graphic data. 


Calling Sequence: CALL DEFINE (ID,ARRAY,N,I,COX,COY,CEX,CEY) 


Arguments: ID - An identification number to be asso¬ 

ciated with this data array. ID must be an 
integer and in the range 1-4. 

ARRAY - The name of an array dimensioned 
(4,N) which is to used for storing graphic 
data. {For further information, see the 
description of data arrays.) 

N - see ARRAY 

I - An integer variabLe equal to the number 
of data items currently in ARRAY. If ARRAY 
is empty when DEFINE is called, I should be 
set to zero. (NOTE: This must not be done 
by placing a zero in the calling list for 
DEFINE.) 

COX,COY,CEX,CEY - The coordinates of the 
lower left and upper right hand corners of 
the area in which user data appears. These 
are used for determining which items in ARRAY 
should be displayed. 
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Name of Subroutine: DSPLAY 


Purpose: 


To display the elements in a previously 
defined data array. 


Calling Sequence: CALL DSPLAY (ID,AXTYP,OX,OY,EX f EY) 


Arguments: 



ID - the ID (1-4) 
displayed. AXTYP - 
displayed: 


of the array to be 
The type of axes to be 


AXTYP 

0 

1 

2 

3 

4 


X 


Y 


no a 
linear 
1inear 
log 
log 


x e s 
linear 
log 

linear 

log 


OX,OY,EX,EY - The coordinates of the lower 
left and upper right hand corners of the 
screen area on which the array is to be 
displayed. 


Notes: The existing elements in the data array are 

scaled from user to screen coordinates and 
displayed. Other displayed arrays are unaf¬ 
fected. * ID' becomes the "current" or 
default id; that is, the id which is assumed C 
in subsequent calls to data routines (LINE, 
POINT, etc.) if an id is not explicitly 
included in the calling list. 



■>* 
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Name of Subroutine: LINE 


Purpose: 


To aid a line to a data array and the current 
display. 


Calling Sequence: 


CALL LINE (XU,Y1,X2,Y2,ID) 


Arguments: X1,Y1,X2,Y2 - The coordinates in user's units 

of the endpoints of the line to be plotted. 

112 ~ (optional) The id of the data array to 

which the point is to be added. If ID is 
omitted, the point is added to the current 
data array. 


Notes: The user's index for the array is incre¬ 

mented. A line takes up two spaces in the 
user’s data array. If the coordinates place 
one of the endpoints outside the display area 
for the array, the line will be clipped. 


PROJECT GRAPHICS 20 



/ 


9TH CONTRACT PERIOD 


FORTRAN GRAPHICS SUBROUTINES 


Name of Subroutine: 

FLPBCD 

Purpose: 

To convert 
form. 

Calling Sequence: 

CALL FLPBCD { 

Arguments: 

VAR - The nam 
translated. 
W,D - The 
decimals plac 
is printed in 
AREA - An ar 
sentation of 
should be at 

Notes: 

If W-6<D or 
(AREA ( 1) ) is 
AREA can be 
to WRITE. 


(This routine 
GPAK.) 


31 JANUARY, 1969 


a real variable to alphanumeric 


VAR , W , D, AREA) 


e of the REAL*4 variable to be 

total field width and number of 
es for the number. The number 
FORTRAN FORMAT EH. D. 
ray into which the EBCDIC repre- 
the number is placed. AREA 
least.W characters long. 


D<0, the first word of AREA 
set to zero. The contents of 
subsequently displayed by a call 


has bean taken in entirety froas 
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Name of Subroutine: FKEY 


Purpose: To provide interactive program control 

through the function keyboard. 


Calling sequence: CALL FKEY (N,BASK) 


Arguments: N - The number of the function key depressed 

(integer 0-31). 

MASK - (optional) The name of a mask which 
determines which keys are to be enabled (see 
below). If this paramter is omitted, all 
keys are enabled. 


Notes: The specified keys are lit, and the computer 

is put into a wait state which is left when 
one of the enabled keys is depressed. Usual¬ 
ly this subroutine will be used with a 
subsequent computed GO-TO statement for pro¬ 
gram branching. 

A mask which determines which keys are 
enabled can be specified using Z format in a 
DATA statement. Each bit (0-31) corresponds 
to a key; if the bit is * 1• the key will be 
enabled. For example, if HASK1 is specified 
by 'DATA MASK 1 /ZFF00C031/*, the instruction 
CALL FKEY (N,HASK1) will light keys 0-7, 
16, 17,26,27, and 31 . 


6 


4 
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Name of Subroutine: LPEN 


Purpose: 


To enable light pen detection of displayed 
graphic data. 


Calling Sequence: CALL LPEN (X, I,ITEM,ID) 


Arguments: X,Y,~ The coordinates of the point, detected. 

ITEM - The index of the item detected. 

IP “ (optional) The id of the data array to 
which the detected item belongs. If ID is 
omitted from the parameter list, it is 
assumed that a detect on an item belonging to 
the current data array is desired; control 
returns to the user only on such a detsction- 
-others are effectively ignored. 


Notes: Detection of a line will result in X,Y being 

set to the actual coordinates of the point 
detected, however ITEM will always be set to 
the index of data item representing the 
second endpoint of the line. 

The X,Y coordinates will be found particular¬ 
ly useful in detecting a point which is part 
of a plot (see description of PLOT) . 

N.B.: In order to insure correct light pen 
correlation (i.e., determining which item in 
a data array was detected), the display 
orders for each data array are generated as a 
block. However, when data items are added to 
data arrays via calls to LINE, POINT, etc., 
the corresponding graphic orders are appended 
to the end of the existing program of graphic 
orders. For this reason, RESEN should be 
called before a call to LPEN if data has 
recently been added in order to insure accur¬ 
ate light pen correlation. 


e 


H 
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Name of Subroutine: FIND 


Purpose: 


To provide coordinate input from the light 
pen. 


Calling Sequence: CALL FIND(X,Y) 


Arguments: X,Y - The coordinates in user's units of the 

light pen position. 

Notes: The screen is temporarily flooded with points 

and a light pen interrupt is sought. When 
the position of the pen is detected, X and Y 
are set to the coordinates of the pen in 
user's units. Note that scaling to user's 
coordinates is always with respect to the 
scale factors of the current data array.No 
change is made to the existing display. 


PROJECT GRAPHICS 28 



9TH CONTRACT PERIOD 


FORTRAN GRAPHICS SUBROUTINES 


31 JANUARY, 1969 
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Name of Subroutine: DELETE 


Purpose: To delete an item from a data array. 

Calling Sequence: CALL DELETE (ITEM,ID) 


Arguments: ITEM - The index corresponding to the item to 

be deleted.ID (optional) - The id of the data 
array from which the item is to be deleted. 
If omitted, the deletion is made from the 
current grid. 


Notes: ITEM can consist of an integer, integer 

variable, or the name of the index associated 
with the data array. (The latter case will 
• result in the last item in the array being 

deleted.) If a line is to be deleted, ITEM 
can correspond to either endpoint; both end¬ 
points will be deleted.Items after the dele¬ 
tion are moved down in the array so as to 
fill up the vacancy left by the deletion. 
The user's index is updated. 


* 
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Name of Subroutine: 

BLANK 

Purpose: 

To render invisible all plotted entities 
associated with a data array (s). 

Calling Sequence: 

CALL BLANK (I D1 , ID2 ,ID3 , . . .) 

Arguments: 

ID 1,ID2,ID3,..- - A list of ids correspond¬ 
ing to the data arrays to be blanked. The 
list must contain at least one id. 


Notes: 

All items in the given data array(s) are 
deleted from the current display. The items 
for each array can be restored by a call to 
UNBLNK or DSPLAY. Blanking an array which is 
already blanked has no effect. 
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Name of Subroutine: UNBLNK 


Purpose: 


To redisplay the items in a previously 
blanked array. 


Calling Sequence: CALL UNBLNK (ID 1,1D2,ID3,...) 


Arguments: IDl r ID2,ID3,..* - A list of ids correspond¬ 

ing to the data arrays to be unblanked. The 
list must contain at least one id. 


Notes: All previously displayed items in the blanked 

array(s) are redisplayed. Unblanking a dis¬ 
play which is already displayed has no 
effect. 
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Name of Subroutine: ERASE 


Purpose: 


To delete all items in a 


data array. 


Calling Sequence: 


CALL ERASE (ID) 


Arguments: 


ID - The id of the data array to be erase!. 


Notes: 


* 


The user's 
zero, thus era 
as far as t 
All data item 
from the cu 
"restore" the 
the array t 
REGEN. 


index for the array is set to 
ptying the array of data items 
he graphics system is concerned, 
s belonging to array are delete! 
rrent display. The user can 
array by resetting the index of 
o its former value and calling 
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Name of Subroutine: CALCMP 


Purpose: 


To provide a hard copy of the current 
display. 


Calling Sequence: 


CALL CALCMP (IHSHT) 


Arguments: 


IHGHY - An integer representing the height in 
inches of the CalComp graph to be generated. 


Notes: 


The screen will be blanked, and the current 
display will be translated into a format 
suitable for CalComp input and written to 
tape. (Note that a DD card for a CalComp 
tape must be included in the job if this 
routine is to be called.) The output of the 
CalComp Plotter will be exactly the same as 
the current display with the exception of the 
scale factor determined by the height of the 
screen (10 inches) as compared with IH3HT. 
When control returns to the user, the current 
display will be restored. The routine may be 
called more than once to provide hard copy 
for several displays. 
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